Currently an increasing number of video streaming techniques make use of so-called segmentation. For example, HTTP adaptive streaming (HAS), Scalable Video Coding (SVC) and spatially segmented video (e.g. tiled video) use segmentation on the basis of time, quality and space respectively. During the segmentation process a so-called manifest file will be generated which describes the relation between the different segment files and/or streams and the location where the segments may be retrieved. A segment file may relate to a file comprising data associated with at least one segment, which may be retrieved by a file retrieval protocol, e.g. HTTP or FTP. Similarly, a segment stream may relate to a stream comprising data associated with at least one segment which may be retrieved by a streaming protocol, e.g. RTSP/RTP or HAS. A segment file or stream hereafter will be referred to as a segment. Further, video, or more in general, content rendered by a segmentation scheme may be referred to as segmented content.
In order to playout (playback) segments in the manifest file, a HAS client (hereafter in short a client) continuously requests segments from the network, typically a so-called content delivery network (CDN). A CDN may be regarded as a managed network of delivery nodes that are configured to deliver segments to clients. A client may use the segments defined in the manifest file to dynamically adjust the playout to changing bandwidth requirements and/or user input, e.g. by switching from a high to a low-quality video stream or vice versa. Moreover, segmented content may also be used by content delivery systems, e.g. CDNs, in order to discriminate between popular and less popular video segments. For example, typically content associated with the beginning of a video will be watched (downloaded/accessed/retrieved) more often (more popular) than content at the end of the video. Similarly, low-bitrate lower-quality video content (e.g. the lowest resolution HAS segments or the so-called SVC base layer) will be watched (downloaded/accessed/retrieved) more frequently than high quality content (e.g. higher-resolution HAS segments or SVC enhancement layers).
The delivery of popular segments to clients from a single, (too) remote server may clog up network bandwidth. Hence, a content delivery network (CDN) that is configured to efficiently deliver content to a consumer may store (cache) the segments associated with more popular content at multiple delivery nodes in the CDN so that potential bandwidth problems may be reduced and efficient delivery is guaranteed. Additionally, a CDN may store popular segments for a longer period on the delivery node. A CDN content location manager may centrally manage the locations within the CDN where the segments may be retrieved and for how long the segments may be retrieved from those locations.
In order to enable a client to access segments stored in a CDN, the client is provided with a so-called manifest file identifying a list of segment identifiers and, optionally, segment locators pointing to locations in the network, which enable the client to retrieve the segments. Typically, a client is configured to retrieve segments such that the segment buffer associated with the client (device) is loaded with a predetermined number of segments before play-out is started. Furthermore, during play-out, the client continuously retrieves segments from the network on the basis of the manifest file so that sufficient segments are kept in a buffer. This way, latencies associated with segment retrieval process do not interfere with the seamless play-out of the segments.
In some cases, however, segments identified in a manifest file may not (yet) be available on the delivery node when a client requests them. The non-availability of a segment may have different reasons. For example, the CDN may be configured not to pre-position segments its delivery nodes before the segments are actually requested. When a segment is requested for the first time, the CDN may trigger an ingestion process wherein a content origin, e.g. media storage or another CDN, may deliver the segments to the CDN (or one or more delivery nodes in the CDN). Such content ingestion scheme may provide the advantage that segments are only stored on the delivery nodes when there is a real demand for the content. Further, in order to efficiently manage the amount of stored segments in the CDN, segments may be available (cached) for a predetermined time. Less popular segments may be stored for relatively short cache period on delivery nodes. After this period the segments are removed, so that when they are requested after the period, the requested segments need to be re-ingested. In another situation, the popularity of segments in e.g. a live stream may suddenly increase steeply so that requested segments are not available on all delivery nodes the moment the request for a segment is received by the delivery node.
In the above-described situations, a segment request may result in the non-availability of a segment (a “cache miss”), which may trigger a process (e.g. a dynamic ingestion process) wherein the requested segments are provided to the delivery node. The ingestion of segments may invoke delays in the segments retrieval process by the client and reduction of the bandwidth that is available to the clients. When the ingestion process needs to be executed for multiple segments, the delivery of the requested segments may be considerably reduced. In order to try to maintain continuous playout, the HAS client perceives this delay as bandwidth problem and may react to such situation by switching over to the playout of a less bandwidth consuming low(er) quality segment steam. This may cause a substantial deterioration in the user experience. In the worst case, the client cannot maintain seamless playout of segments.
US2009/0292819 describes a method wherein during conventional playout of a media stream the client may prefetch “look-ahead” segments from a media server. This way a client may easily skip to the look-ahead segments without any substantial delays. In practice such prefetch scheme will lead to a situation wherein during the normal streaming process additional “look-ahead” segments are retrieved so that there is less bandwidth available between the client and the media server for the regular segments. If one would use such scheme in an adaptive streaming system, the HAS client would react to the bandwidth reduction by switching over to a segmented stream of lower quality.
Hence, there is a need in the art for improved method and systems for streaming of segmented content to a client. In particular, there is a need for methods and systems providing seamless play-out of segmented content even in the case that not all segments in a manifest file are available for delivery to the client the moment the client receives the manifest file.